IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 
BEFORE THE BOARD OF PATENT APPEALS AND INTERFERENCES 



In re Application of: § Group Art Unit: 2154 

§ 

Bernard A. Traversat, et al. § Examiner: Nguyen, Dustin 

§ 

§ Atty. Dkt. No.: 5681-07700 
§ P7116 

§ 

Serial No. 10/055,666 § 

§ 
§ 

Filed: January 22, 2002 § 

§ 

For: RESOURCE IDENTIFIERS § 
FOR A PEER-TO-PEER § 
ENVIRONMENT § 

AMENDED APPEAL BRIEF 

Mail Stop Appeal Brief - Patents 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 



Sir/Madam: 

This brief is submitted in response to the Notification of Non-Compliant Appeal 
Brief of December, 12 2007. Appellants respectfully request that the Board of Patent 
Appeals and Interferences consider this appeal. 
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I. 



REAL PARTY IN INTEREST 



As evidenced by the assignment recorded at Reel/Frame 012529/0758, the subject 
application is owned by Sun Microsystems, Inc., a corporation organized and existing 
under and by virtue of the laws of the State of Delaware, and now having its principal 
place of business at 4150 Network Circle, Santa Clara, CA 95054. 
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II. RELATED APPEALS AND INTERFERENCES 



No other appeals, interferences or judicial proceedings are known which would be 
related to, directly affect or be directly affected by or have a bearing on the Board's 
decision in this appeal. 
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III. STATUS OF CLAIMS 



Claims 3, 21-29, 42-47 and 50 have been canceled. Claims 1-2, 4-20, 30-41 and 
48-49 and 51-79 are pending and stand finally rejected. The rejection of claims 1-2, 4- 
20, 30-41 and 48-49 and 51-79 is being appealed and a copy of claims 1-2, 4-20, 30-41 
and 48-49 and 51-79 as currently pending is included in the Claims Appendix herein 
below. 



10/055,666 (5681-07700/P7116) 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



IV. STATUS OF AMENDMENTS 

No amendments have been submitted subsequent to the final rejection. 
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V. 



SUMMARY OF CLAIMED SUBJECT MATTER 



Independent claim 1 is directed to a peer computing system including a plurality 
of peer nodes operable to couple to a network (See, e.g., FIG.1A-B, 13-17, 19-30, items 
104A-104F, and 200A-200G; page 7, lines 3-14). The plurality of peer nodes implement 
a peer-to-peer environment (See, e.g., FIG 2, all items; page 14, lines 15-23) on the 
network according to a peer-to-peer platform (See, e.g., FIG 2, all items; page 14, lines 
15-23; page 15, lines 4-17). 

The peer-to-peer platform includes a core layer (See, e.g., FIG 2, items 120, 122, 
124, 126, 128, and 130; page 14, lines 18-23 and lines 25-30; page 16, line 4 - page 17, 
line 23), a service layer (See, e.g., FIG 2, items 140, 142, 144; page 19, line 1 - page 20, 
line 10), and a unique peer identifier (See, e.g., FIG 2, items 140, 142, 144; page 15, line 
19 - page 16, line 2; page 50, line 4-5). The core layer includes peer-to-peer platform 
protocols for enabling the plurality of peer nodes to discover each other (See, e.g., FIG 2, 
item 124; FIG. 13, item 206; FIG. 14, item 208; FIGs. 15-18, all items; FIG. 31-32, items 
502, 504, 522, 524; page 7, lines 3-23; page 14, lines 15-23; page 15, lines 4-17; page 17, 
lines 1-13), communicate with each other (See, e.g., FIG 2, item 124; FIG. 13, item 206; 
FIG. 14, item 208; FIGs. 15-18, all items; FIG. 31-32, items 502, 504, 522, 524; page 7, 
lines 3-23; page 14, lines 15-23; page 15, lines 4-17; page 17, lines 1-13) and cooperate 
with each other to form peer groups and share content in the peer-to-peer environment 
(See, e.g., FIGs. 13, 14, 19, items 210A-210B; page 7, lines 7-23; page 14, lines 15-23; 
page 15, lines 4-30; page 16, lines 4-16; page 19, line 19 - page 20, line 10; page 23, line 
1 1 - page 24, line 8; page 29, line 24 - page 30, line 30). 

The service layer includes services that are provided by the plurality of peer nodes 
in the peer-to-peer environment (See, e.g., FIG 2, items 140, 142, 144; page 13, lines 3- 
17; page 19, line 1 - page 20, line 10). At least a subset of the services are operable to be 
used by the peer nodes in forming peer groups and participating in the peer groups (See, 
e.g., FIGs. 13, 14, 19, items 210A-210B; page 7, lines 7-23; page 14, lines 15-23; page 
15, lines 4-30; page 16, lines 4-16; page 19, line 19 - page 20, line 10; page 23, line 11 - 
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page 24, line 8). Additionally, each of the services is configured to be accessed by the 
peer nodes in accordance with at least one of the peer-to-peer platform protocols (See, 
e.g., page 29, line 24 - page 30, line 30). 

The unique peer identifier is configured for use in distinguishing a particular peer 
node from others of the peer nodes and is independent of a network address of the 
particular peer node (See, e.g., page 15, line 19 - page 16, line 2; page 23, line 1 1 - page 
24, line 8). Each of the peer nodes is also configured to access another of the peer nodes 
one the network using the unique peer identifier of the other peer node without using a 
network address of the other peer node (See, e.g., page 15, line 19 - page 16, line 2; page 
23, line 1 1 - page 24, line 8; page 28, lines 13-21; page 29, lines 1 1-22). 

Independent claim 30 is directed to a peer node including a network interface for 
coupling to a network and a memory including program instructions executable within 
the peer node (See, e.g., FIG.1A-B, 13-17, 19-30, items 104A-104F, and 200A-200G; 
page 7, lines 3-14). The program instructions are executable within the peer node to 
implement, according to a peer-to-peer platform, a core layer(5ee, e.g., FIG 2, items 120, 
122, 124, 126, 128, and 130; page 14, lines 18-23 and lines 25-30; page 16, line 4 - page 
17, line 23), a service layer (See, e.g., FIG 2, items 140, 142, 144; page 19, line 1 - page 
20, line 10), and a unique peer identifier (See, e.g., FIG 2, items 140, 142, 144; page 15, 
line 19 - page 16, line 2; page 50, line 4-5). 

The core layer includes one or more peer-to-peer platform protocols for enabling 
the peer node to discover other peer nodes (See, e.g., FIG 2, item 124; FIG. 13, item 206; 
FIG. 14, item 208; FIGs. 15-18, all items; FIG. 31-32, items 502, 504, 522, 524; page 7, 
lines 3-23; page 14, lines 15-23; page 15, lines 4-17; page 17, lines 1-13), communicate 
with each other (See, e.g., FIG 2, item 124; FIG. 13, item 206; FIG. 14, item 208; FIGs. 
15-18, all items; FIG. 31-32, items 502, 504, 522, 524; page 7, lines 3-23; page 14, lines 
15-23; page 15, lines 4-17; page 17, lines 1-13) and cooperate with each other to form 
peer groups and share content in the peer-to-peer environment (See, e.g., FIGs. 13, 14, 
19, items 210A-210B; page 7, lines 7-23; page 14, lines 15-23; page 15, lines 4-30; page 
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16, lines 4-16; page 19, line 19 - page 20, line 10; page 23, line 1 1 - page 24, line 8; page 
29, line 24 - page 30, line 30). 

The service layer includes services that are provided by the plurality of peer nodes 
in the peer-to-peer environment (See, e.g., FIG 2, items 140, 142, 144; page 13, lines 3- 
17; page 19, line 1 - page 20, line 10). At least a subset of the services are operable to be 
used by the peer nodes in forming peer groups and participating in the peer groups (See, 
e.g., FIGs. 13, 14, 19, items 210A-210B; page 7, lines 7-23; page 14, lines 15-23; page 
15, lines 4-30; page 16, lines 4-16; page 19, line 19 - page 20, line 10; page 23, line 11 - 
page 24, line 8). Additionally, each of the services is configured to be accessed by the 
peer nodes in accordance with at least one of the peer-to-peer platform protocols (See, 
e.g., page 29, line 24 - page 30, line 30). 

The unique peer identifier is configured for use in distinguishing a particular peer 
node from others of the peer nodes and is independent of a network address of the 
particular peer node (See, e.g., page 15, line 19 - page 16, line 2; page 23, line 1 1 - page 
24, line 8). Each of the peer nodes is also configured to access another of the peer nodes 
one the network using the unique peer identifier of the other peer node without using a 
network address of the other peer node (See, e.g., page 15, line 19 - page 16, line 2; page 
23, line 1 1 - page 24, line 8; page 28, lines 13-21; page 29, lines 1 1-22). 

Independent claim 48 is directed to a method for implementing a peer-to-peer 
environment on a network that includes a plurality of peer nodes coupled to a network 
each implementing a core layer of a peer-to-peer platform (See, e.g., FIG.1A-B, 13-17, 
19-30, items 104A-104F, and 200A-200G; page 7, lines 3-1; FIG 2, all items; page 14, 
lines 15-23; page 15, lines 4-17). 

The core layer includes peer-to-peer platform protocols for enabling the plurality 
of peer nodes to discover each other (See, e.g., FIG 2, item 124; FIG. 13, item 206; FIG. 
14, item 208; FIGs. 15-18, all items; FIG. 31-32, items 502, 504, 522, 524; page 7, lines 
3-23; page 14, lines 15-23; page 15, lines 4-17; page 17, lines 1-13), communicate with 
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each other (See, e.g., FIG 2, item 124; FIG. 13, item 206; FIG. 14, item 208; FIGs. 15-18, 
all items; FIG. 31-32, items 502, 504, 522, 524; page 7, lines 3-23; page 14, lines 15-23; 
page 15, lines 4-17; page 17, lines 1-13) and cooperate with each other to form peer 
groups and share content in the peer-to-peer environment (See, e.g., FIGs. 13, 14, 19, 
items 210A-210B; page 7, lines 7-23; page 14, lines 15-23; page 15, lines 4-30; page 16, 
lines 4-16; page 19, line 19 - page 20, line 10; page 23, line 1 1 - page 24, line 8; page 29, 
line 24 - page 30, line 30). 

Each of the peer nodes also implements, as part of the method of claim 48, a 
service layer (See, e.g., FIG 2, items 140, 142, 144; page 19, line 1 - page 20, line 10) 
including services each provided by one or more of the peer nodes (See, e.g., FIG 2, 
items 140, 142, 144; page 13, lines 3-17; page 19, line 1 - page 20, line 10). Each of the 
services is configured to be accessed by peer nodes in accordance with at least a subset of 
the peer-to-peer platform protocols (See, e.g., page 29, line 24 - page 30, line 30). 

The method of claim 48 also includes assigning a unique peer identifier to each of 
the plurality of peer nodes (See, e.g., page 15, line 19 - page 16, line 2; page 23, line 11- 
page 24, line 8). Each unique peer identifier is configured for use in distinguishing a 
particular peer node from other of the plurality of peer nodes and is independent of a 
network address of the particular peer node (See, e.g., FIG 2, items 140, 142, 144; page 
15, line 19 - page 16, line 2; page 50, line 4-5). The method also includes one of the peer 
nodes accessing another of the peer nodes using the unique peer identifier of the other 
peer node without using a network address of the other peer node (See, e.g., page 15, line 
19 - page 16, line 2; page 23, line 11 - page 24, line 8; page 28, lines 13-21; page 29, 
lines 11-22). 

Independent claim 66 is directed to an article of manufacture including software 
instructions executable to implement a plurality of peer nodes (See, e.g., FIG.1A-B, 13- 
17, 19-30, items 104A-104F, and 200A-200G; page 7, lines 3-14) couple to a network 
each implementing a core layer of a peer-to-peer platform (See, e.g., FIG 2, items 120, 
122, 124, 126, 128, and 130; page 14, lines 18-23 and lines 25-30; page 16, line 4 - page 
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17, line 23). The core layer includes peer-to-peer platform protocols for enabling the 
plurality of peer nodes to discover each other (See, e.g., FIG 2, item 124; FIG. 13, item 
206; FIG. 14, item 208; FIGs. 15-18, all items; FIG. 31-32, items 502, 504, 522, 524; 
page 7, lines 3-23; page 14, lines 15-23; page 15, lines 4-17; page 17, lines 1-13), 
communicate with each other (See, e.g., FIG 2, item 124; FIG. 13, item 206; FIG. 14, 
item 208; FIGs. 15-18, all items; FIG. 31-32, items 502, 504, 522, 524; page 7, lines 3- 
23; page 14, lines 15-23; page 15, lines 4-17; page 17, lines 1-13) and cooperate with 
each other to form peer groups and share content in the peer-to-peer environment (See, 
e.g., FIGs. 13, 14, 19, items 210A-210B; page 7, lines 7-23; page 14, lines 15-23; page 
15, lines 4-30; page 16, lines 4-16; page 19, line 19 - page 20, line 10; page 23, line 11 - 
page 24, line 8; page 29, line 24 - page 30, line 30). 

The software instructions are also executable to implement the plurality of peer 
nodes each implementing a service layer (See, e.g., FIG 2, items 140, 142, 144; page 19, 
line 1 - page 20, line 10) including services provided by the plurality of peer nodes. 
Each service is provided by one or more of the peer nodes and is configured to be 
accessed by peer nodes in accordance with at least a subset of the peer-to-peer platform 
protocols (See, e.g., FIGs. 13, 14, 19, items 210A-210B; page 7, lines 7-23; page 14, lines 
15-23; page 15, lines 4-30; page 16, lines 4-16; page 19, line 19 - page 20, line 10; page 
23, line 1 1 - page 24, line 8). 

The software instructions are further executable to implement assigning a unique 
peer identifier to each of the peer nodes (See, e.g., page 15, line 19 - page 16, line 2; 
page 23, line 11 - page 24, line 8). Each peer identifier is configured for use in 
distinguishing the respective peer node from others of the peer nodes and is independent 
of a network address of the respective peer node (See, e.g., FIG 2, items 140, 142, 144; 
page 15, line 19 - page 16, line 2; page 50, line 4-5). Each of the peer nodes is 
configured to access another of the peer nodes using the unique peer identifier of the 
other peer node without using a network address of the other peer node (See, e.g., page 
15, line 19 - page 16, line 2; page 23, line 1 1 - page 24, line 8; page 28, lines 13-21; page 
29, lines 11-22). 
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The summary above describes various examples and embodiments of the claimed 
subject matter; however, the claims are not necessarily limited to any of these examples 
and embodiments. The claims should be interpreted based on the wording of the 
respective claims. 
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VI. 



GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 



1. Claims 1, 2, 4-20, 30-41, 48, 49 and 51-79 stand rejected under the 
judiciary created doctrine of obviousness-type double patenting as being unpatentable 
over claims of U.S. Patent No. 7,065,579. 

2. Claims 1, 2, 4-13, 15, 17-20, 30-37, 39, 48, 49, 51-59, 61, 63, 65-74, 76 
and 78 stand finally rejected under 35 U.S.C. § 102(e) as being anticipated by Weisman 
et al. (U.S. Publication 2002/01 12058) (hereinafter "Weisman"). 

3. Claims 14, 16, 38, 40, 41, 60, 62, 64, 75, 77 and 79 stand finally rejected 
under 35 U.S.C. § 103(a) as being unpatentable over Weisman in view of Ferguson et al. 
(U.S. Patent 6,490,618) (hereinafter "Ferguson"). 
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VII. ARGUMENT 



First Ground of Rejection 

Claims 1, 2, 4-20, 30-41, 48, 49 and 51-79 stand rejected under the judiciary 
created doctrine of obviousness-type double patenting as being unpatentable over claims 
of U.S. Patent No. 7,065,579. Appellants respectfully traverse this rejection for at least 
the following reasons. 

The Examiner supports this rejection by stating that "the applications are claiming 
common subject matter" and listing three claim terms that the Examiner asserts are 
common to both the instant application and the '579 patent. The Examiner also states 
that the '679 patent does not claim the service layer as in the instant application, but 
asserts that it would have been obvious "that the mechanism for accessing services of 
[the] '579 patent is ... similar in functionality to the service layer of the instant 
application." However, stating that the applications claim "common subject mater" and 
similar functionality is not a proper reason for holding the claims of the present 
application obvious from the claims of the listed applications. The Examiner's assertions 
are completely conclusory. 

According to MPEP 804.II.B.1, "the analysis employed in an obviousness-type 
double patenting determination parallels the guidelines for a 35 U.S.C. 103(a) rejection." 
This section of the MPEP also states that the same "factual inquires . . . that are applied 
for establishing a background for determining obviousness under 35 U.S.C. 103(a) are 
employed when making an obviousness-type double patenting analysis." MPEP 
804.II.B.1 also states that the Examiner should list the differences between each rejected 
claim and the claims of the other patent/application, and for each difference the Examiner 
should give the reasons why a person of ordinary skill in the art would conclude that the 
invention defined in the claim is an obvious variation of the invention defined in a claim 
of the other patent/application. 

Simply stating that the instant application and the '579 patent claim "common 
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subject matter" and are "similar in functionality" is not a valid reason why a person of 
ordinary skill in the art would conclude that the invention defined in each claim is an 
obvious variation of the invention defined in a claim of the other patent/application. Nor 
has the Examiner specifically addressed each difference of each claim of the present 
application compared to the claims of the other applications. Instead, the Examiner 
improperly lumped all the claims together and did not address each specific difference. 
The Examiner clearly has not met the requirements stated in MPEP 804.II.B.1 to 
establish a prima facie obviousness-type double patenting rejection. 

In the Advisory Action, the Examiner presents a table to "show the similarity and 
differences" between Appellants' claims and the '579 patent. However, rather than 
listing the differences between each rejected claim and the claims of the '579 patent, the 
Examiner merely listed a combination of Appellants' claims 1 and 18 and claim 1 of the 
'579 patent. However, although the chart provided by the Examiner clearly shows 
differences between the claims, the Examiner did not even attempt to specifically identify 
all the differences and prove a prima facie case of obviousness in regard to each 
difference. The table presented by the Examiner in the Advisory Action clearly shows 
additional differences between the Appellants' claims and the claims of the '579 patent 
that are not addressed in any fashion by the Examiner. Even a cursory review of the 
Examiner's table illustrates that the Examiner has failed to address all the differences 
between the respective claims. For instance, the Examiner does not address the fact that 
Appellants' claim 1 recites a unique peer identifier which, according to the Examiner's 
table, is not recited in the claims of the '579 patent. In fact, the Examiner appears to have 
omitted several limitations of Appellants' claim 1 from the table in the Advisory Action. 
For example, limitations recited in Appellants' claim 1 regarding the unique peer 
identifier being independent of a network address of the particular peer node are not 
addressed (either as a similarity or a difference) in the Examiner's claim table. Nor does 
the Examiner's table include the limitation from Appellants' claim 1 that a peer node 
accessing another peer node using a unique peer identifier for the other peer node does 
not use a network address of the other peer node. Instead, the Examiner only discusses a 
processor, network interface and memory. 
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Moreover, even though the Examiner has rejected 1-20, 30-41 and 48-79 in the 
double patenting rejection, the Examiner has only attempted any analysis in regard to 
claims 1 and 18. Therefore the Examiner clearly failed to provide a prima facie double 
patenting rejection of claims 2, 4-17, 19-20, 30-41, 48, 49 and 51-79. 

Therefore, the Examiner has clearly failed to provide a prima facie double 
patenting rejection by failing to list each differences between each rejected claim and the 
claims of the other patent/application, and provide a factual basis establishing the 
obviousness of each difference. The Examiner has failed to give reasons, for each 
difference, why a person of ordinary skill in the art would conclude that the invention 
defined in the Appellants' claims is an obvious variation of the invention of the '579 
patent. In the Advisory action the Examiner merely states that it would have been 
obvious to include a processor, network interface and memory in Appellants' claims 
because it "would enable the plurality of peer nodes to communicate and exchange 
information with each other." However, the Examiner's stated motivation is clearly a 
generic statement of peer node functionality that does not provide any motivation for the 
specific differences pointed out by the Examiner (e.g., a processor, network interface and 
memory). Nor does the Examiner's reasoning address numerous other differences 
between the claims. 

Accordingly, Appellants respectfully request removal of the double patenting 
rejection of claims 1, 2, 4-20, 30-41, 48, 49 and 51-79. 

Second Ground of Rejection 

Claims 1, 2, 4-13, 15, 17-20, 30-37, 39, 48, 49, 51-59, 61, 63, 65-74, 76 and 78 
stand finally rejected under 35 U.S.C. § 102(e) as being anticipated by Weisman et al. 
(U.S. Publication 2002/0112058) (hereinafter "Weisman"). Appellants respectfully 
traverse this rejection for at least the following reasons. 
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Weisman is not prior art to the present application. 



The rejection is improper because Weisman is not a prior art reference. 

More specifically, the Weisman publication was filed on June 1, 2001, after Applicants' 
priority date of April 24, 2001. Therefore, the rejection is improper since Weisman is not 
prior art. 

More specifically, the Weisman publication was filed on June 1, 2001, after 
Applicants' priority date of April 24, 2001. Weisman does claim the benefit of a 
provisional application filed December 1, 2000. However, the December 1, 2000 filing 
date can only be used as Weisman's 35 U.S.C. § 102(e) prior art date for the subject 
matter that is common to both the Weisman publication and the provisional application. 
A review of Weisman's provisional application reveals that it varies considerably from 
Weisman's published utility application. 

For example, Weisman's provisional application appears to be a reference manual 
to using the UPnP API. However, Weisman's provisional application does not appear to 
disclose or mention anything regarding using the UPnP API for peer-to-peer networking 
purposes, as relied on by the Examiner in the rejection of Applicants' claims. Unless the 
Examiner can prove that the subject matter on which the Examiner is relying on to reject 
Appellants' claims is also entirely present in Weisman's provisional application, the 
rejection is improper. See, In re Wertheim, 209 USPQ 554 (CCPA 1981). 

The burden to establish a proper rejection, including proving that Weisman's 
provisional application supports the subject matter relies on by the Examiner from 
Weisman's published utility application, clearly falls on the Examiner, not the Applicant. 
See, In re Werner, 154 USPQ 173, 177 (CCPA 1967), cert, denied, 389 US 1057 (1968). 

Furthermore, the Board of Patent Appeals and Interferences recently discussed the 
requirements of a prima facie rejection relying on a utility application filed after the 
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application under examination but which claimed prior to the filing date of a provisional 
application. The Board reiterated that the "allocation of burden requires that the USPTO 
produce the factual basis for its rejection of an application under USC 102 and 103" and 
that "[t]he one who bears the initial burden of presenting a prima facie case of 
unpatentability is the Examiner." See, Decision On Appeal, U.S. Patent Application No. 
10/054,809, August 31, 2007, p. 8, lines 1-20 (the Board stated that the Examiner's 
"rejection should show, to establish a prima facie case for unpatentablity, where support 
resides in the earlier provisional applications for each instance of specific subject matter 
relied upon in the published application, including an explanation why the provisionals 
would still be recognized by the artisan as providing support if not 'word for word' the 
same as the later text or drawings ." (emphasis added). This is the exactly the situation in 
the instant case, namely that the Examiner has failed to provide a prima facie rejection 
because Weisman's utility application is not prior and the Examiner has not shown that 
Weisman's provisional application fully supports every instance of the subject matter of 
Weisman's later utility relied on by the Examiner. 

Additionally, the Weisman publication is not entitled to the June 30, 1999 
date as a section 102(e) prior art date unless at least one claim of the Weisman 
published application is supported (under 35 U.S.C. § 112) in the provisional 
application. Under 35 U.S.C. 119(e)(1), an application is not entitled to a provisional 
application's filing date as a prior art date unless at least one claim of the published utility 
application is supported (per 35 U.S.C. § 1 12) in the provisional application. Weisman's 
provisional application does not appear to fully support the claims of Weisman's utility 
application. For example, Weisman's provisional application does not appear to support 
peer networking protocol limitations of claim 1 in Weisman's utility application. The 
rejection is improper unless the Examiner can show that Weisman's published 
application has the necessary claim support in the provisional application to be entitled to 
the provisional application's filing date as its § 102(e) prior art date. See also M.P.E.P. § 
2136.03(IV). Since the Examiner has not provided the necessary evidence to show that 
the Weisman publication is prior art to the present application, the current rejection is 
improper. 
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Moreover, no benefit claim to an earlier application was ever perfected in 
Weisman. An examination of the specification and file history of Weisman's published 
utility application does not show that Weisman's published utility application was ever 
amended to contain a specific reference to Weisman's provision application, as required 
by 35 U.S.C. § 119(e)(1). Thus, there is no valid and perfected claim for benefit of the 
provisional application in Weisman's published utility application. Therefore, 
Weisman's published utility application is only entitled to its own filing date (which is 
subsequent to the present application effective filing date) as a prior art date. Therefore, 
the rejection is improper since Weisman is not prior art. 

Additional arguments for different groups of claims are addressed under their 
respective subheadings as follows. 

Claims 1. 4. 7. 9. 13. 18. 30. 33. 36. 37. 39. 48. 54. 56. 58. 59. 61. 63. 66. 69. 71. 
73. 74. and 76; 

Weisman fails to disclose that each of the plurality of peer nodes is further 
configured to access another of the plurality of peer nodes on the network using the 
unique peer identifier of the other peer node, wherein the peer node does not use a 
network address of the other peer node to access the other peer node . The Examiner 
cites paragraphs 863-904 of Weisman. However, the cited passage does not describe a 
peer node accessing another peer node using the unique peer identifier of the other peer 
node, wherein the peer node does not use a network address of the other peer node to 
access the other peer node. Instead, this passage describes the contents of the NOTIFY 
multicast message that a device broadcasts when added to the network. 

Weisman teaches that to access another device, messages are sent to the device's 
control URL, which is a combination of the network URL of the device and a unique 
identifier for the particular target service on the device. Specifically, Weisman teaches 
that a service's control URL includes the path to the device, the UDN of the device, the 
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service ID and a randomly generated string (Weisman, paragraphs 122, 130-137, 815, 
and 1 148 - 1 150). Since a device's control URL is not independent of, and clearly uses, 
the network address of the device, Weisman fails to teach a peer node accessing another 
peer node using the unique peer identifier of the other peer node, wherein the peer node 
does not use a network address of the other peer node to access the other peer node. 

In the response to arguments of the Final Office Action and the Advisory Action, 
the Examiner cites paragraphs 45, 122, 131-137, 183 and 376 of Weisman and describes 
how Weisman' s Web Server invokes an automation proxy for a service to cause the 
service to execute a control request. The Examiner states Weisman's device host API 
sets up control URL's of hosted devices to point to the Web Server. The Examiner further 
describes how Weisman's system format the URL and uuid that make up the address 
used to invoke control requests on the service object. 

The Examiner states that "Weisman discloses the Device Host API sets up the 
control URLs of hosted devices 108-110 to point to the Web Server, when the Web 
Server receives an HTTP request with one of the hosted devices ' control URLs, the Web 
Server invoke[s] the Automation Proxy for the service to execute the control request" 
(italics added). The Examiner also states (in the Advisory Action), "Weisman uses URL 
address for peer accessing, not the network address as claimed, as broadly and reasonably 
interpreted, as Internet Protocol (IP) or MAC addresses". Thus, the Examiner contends 
that Weisman's URLs cannot be "broadly and reasonably interpreted" as a network 
addresses. 

However, Weisman teaches that his system uses relative URLs that are then 
appended to a base URL from the device description (Weisman, paragraphs 61, 1009, 
1022, 1035, 1043). Elsewhere Weisman states that control messages are sent to the 
control URL for the service that is provided in the device description (paragraph 0815). 
Weisman also teaches that the base URL is a network address. For instance, when 
describing how a node sends a requested action to a device, Weisman describes a 
"[d]omain name or IP address ... of URL for control [of] this service" that Weisman 
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describes as a "control URL sub element from device description" (paragraphs 1279 - 
1287). 

Weisman also teaches that when a device is added to the network it sends a 
discovery message that includes a URL for communicating with the device that is "sent 
in a LOCATION header" (paragraphs 853-857). Weisman states that a LOCATION 
header may contain an IP address or a domain name (paragraphs 878-879). In 
Weisman's system a network address (URL) is used when one peer is accessing another. 
The fact that Weisman's system also includes other information, such as the uuid does 
not change the fact that a network address is also used. Thus, Weisman clearly teaches 
the use of network addresses to communicate with other nodes and devices. 

Anticipation requires the presence in a single prior art reference disclosure of each 
and every limitation of the claimed invention, arranged as in the claim . M.P.E.P 2131; 
Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 
485 (Fed. Cir. 1984). The identical invention must be shown in as complete detail as is 
contained in the claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. 
Cir. 1989). As discussed above, Weisman fails to disclose where each of the plurality of 
peer nodes is further configured to access another of the plurality of peer nodes on the 
network using the unique peer identifier of the other peer node, wherein the peer node 
does not use a network address of the other peer node to access the other peer node . 
Therefore, Weisman cannot be said to anticipate claim 1 . 

Claims 2, 6, 31, 32, 49, 51, 53, 67 and 68: 

Weisman fails to disclose where each of the plurality of peer nodes is further 
configured to bind a peer identifier corresponding to the particular peer node to the 
network address of the particular peer node . The Examiner cites paragraphs 181-124 of 
Weisman. The cited passage describes the addressing within Universal Plug-n-Play 
(UPnP) networking. Weisman teaches that a device may use an automatic IP addressing 
facility to obtain an address. However, the cited passage does not mention any peer 
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nodes configured to bind a peer identifier corresponding to the particular peer node to the 
network address of the particular peer node. Instead, the cited passage only describes 
how a peer node may automatically obtain, such as via DHCP, an IP address. Weisman 
does not describe any peer node binding a peer identifier to a network address of a 
particular peer node. 

In the response to arguments of the Final Office Action, the Examiner cites 
paragraphs 833 - 837 of Weisman referring to Weisman's mapping of a device's DNS 
name to its IP address. However, the cited passages make no mention of a peer node 
binding a peer identifier of another peer node to the network address of the other peer 
node. Instead, the cited passage of Weisman describes how a computer that needs to 
contact a device may use a DNS query to discover the devices IP address. Merely 
discovering an IP address of another device cannot be considered binding a peer 
identifier to a network address. Weisman states that the DNS mappings are used to 
ensure that the device can still be found even when the IP address changes (Weisman, 
paragraphs 834 - 835). Thus, Weisman teaches that a computer should lookup IP 
addresses using a DNS server specifically because IP address may change and the 
devices name can be used to lookup a changed IP address. Weisman's peers clearly do 
not bind network address to peer identifiers. 

Claims 5 and 52: 

Weisman also fails to disclose wherein, to access the other peer node, the unique 
peer identifier of the other peer node is configured to be mapped to one of the one or 
more network interfaces of the other peer node . The Examiner cites paragraphs 7 and 63 
of Weisman. However, neither of these paragraphs describes a peer identifier being 
mapped to a network interface of the other peer node. Instead, paragraph 7 describes a 
device hosting framework that listens for control requests and translates control requests 
into calls to the service objects' programming interfaces (e.g. IDispatch interfaces). 
However, IDispatch interfaces are not network interfaces. Paragraph 63 teaches that 
service interfaces are written in UTL in service descriptions and how a hosted device 
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provides a COM object that exposes the service's interface. Thus, the Examiner has 
failed to cite any portion of Weisman that discloses that the unique peer identifier of the 
other peer node is configured to be mapped to one of the one or more network interfaces 
of the other peer node . Moreover, nowhere does Weisman describe that a service's 
UDN, which the Examiner equates to the unique peer identifier Appellants' claims, is 
configured to be mapped to a network interface of a peer node. 

In the response to arguments of the Final Office Action, the Examiner cites 
paragraphs 36, 37, 67 and 68 of Weisman. The Examiner argues that Weisman's system 
translates control requests into calls to a service's IDispatch interfaces. However, 
translating control requests into calls to the service objects' programming interfaces (e.g. 
IDispatch interfaces) does not disclose a unique peer identifier of a peer node configured 
to be mapped to a network interface of the peer node. A programming interface is not a 
network interface. Moreover, it is well known that IDispatch interfaces, such as those 
taught by Weisman, provide a programmatic interface to find out what properties and 
method are supported by an object-oriented programming object. 

Additionally, Weisman teaches that the Device Host listens for and receives 
control requests and then locates and calls the IDispatch interface for the hosted service. 
Weisman describes a hosted device as a software module that executes on the same 
machine as the Device Host. Thus, the translation referred to by the Examiner clearly 
involves the Device Host programmatically invoking the service interface of a hosted 
device. The Device Host does not translate the control into a network interface nor does 
it map a UDN to a network interface. 

Thus, Weisman clearly fails to disclose a unique peer identifier mapped to one of 
the one or more network interfaces. Therefore, Weisman does not anticipate Appellants' 
claim. 

Claims 8, 55 and 70 : 
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Weisman fails to disclose wherein each of the plurality of peer nodes is assigned a 
different unique peer identifier in accordance with the peer-to-peer platform for each of 
the one or more peer groups in which the peer node is a member peer . The Examiner 
refers to Weisman's container identifier, citing paragraphs 85, 105 and 489. However, 
Weisman only teaches that a container is a string that identifies the group to which the 
device belongs and that all devices with the same container identifier will be hosted in the 
same process. Nowhere does Weisman mention that each peer node is assigned a 
different unique peer identifier for each of the peer groups in which the peer node is a 
member peer. Weisman merely states that a container identifier identifies the group to 
which a device belongs. Weisman clearly fails to disclose wherein each of the plurality 
of peer nodes is assigned a different unique peer identifier in accordance with the peer-to- 
peer platform for each of the one or more peer groups in which the peer node is a member 
peer. 

In the response to arguments of the Final Office Action, the Examiner further 
cites paragraphs 1513 and 1539 of Weisman and refers to Weisman's event subscription 
process. Weisman teaches that a service may publish event messages to interested 
control points, called subscribers (paragraph 1497). The Examiner refers to the fact that 
if a subscription expires, the subscription identifier becomes invalid and the control point 
sends a subscription message to get a new subscription identifier. First of all, Weisman's 
subscription identifiers have nothing to do with the container identifiers that the 
Examiner relies upon in the rejection of claim 8. Furthermore, the fact that each 
subscriber is provided with a unique subscription identifier has no relevance to a peer 
node being assigned a different unique peer identifier for each peer group in which the 
peer node is a member. Weisman's event publishing does not have anything to do with 
peer group membership. 

Claims 10, 11,35, 57 and 72 : 

Weisman fails to disclose that a peer node hosts a plurality of instances of a 
resource, where each of the instances of the resource is hosted for a different one of the 
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plurality of peer groups . The Examiner refers to Weisman's web server identifying 
service instances, citing paragraphs 131-137. This passage describes the formatting and 
use of Weisman's control URLs. For example, Weisman teaches in cited passage that his 
web server locates a service implementation using the service instance name from the 
control URL. 

However, Weisman does not mention, either at the Examiner's cited passage or 
elsewhere, anything regarding a peer node hosting multiple instances of a resource, where 
each instance is hosted for a different peer group. In fact, the cited passage does not 
mention peer groups at all. Nor does the cited passage mention anything regarding 
subscriptions, which the Examiner equates to the peer groups of Appellants' claims. 
Thus, Weisman fails to disclose a peer node hosting a plurality of instances of a resource, 
where each of the instances is hosted for a different peer group. 

Claims 12. 15 and 17 : 

Weisman fails to disclose a peer advertisement format for describing and 
publishing advertisements for peer nodes in the peer-to-peer environment, wherein 
each of the plurality of peer nodes is further configured to generate a peer 
advertisement for the particular peer node , wherein the peer advertisement includes 
a peer identifier for the peer node. The Examiner cites paragraphs 848-860 and relies 
on Weisman's discovery advertisement. However, each peer node of Weisman's system 
is not configured to generate a peer advertisement for the particular peer node . The 
Examiner's cited passage describes how when a device is added to Weisman's network, 
the discovery protocol allows that device to advertise its services by repeatedly 
multicasting discovery messages that "advertise the full extent of its capabilities" 
(Weisman, paragraph 849). Weisman does not mention anything about each peer node 
generating a peer advertisement for a particular peer node, as recited in Appellants' 
claim. 
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According to the Examiner's line of reasoning, each peer of Weisman's system 
would have to generate an advertisement for a particular peer node. Instead, however, 
Weisman teaches (such as at the Examiner's cited passage) a discovery advertisement 
protocol in which each device repeatedly multicasts an advertisement of its, respective, 
capabilities. Weisman does not discuss, either at the cited passage or elsewhere, 
anything regarding each peer generating an advertisement for a particular peer. 

Claims 19 and 65 : 

Weisman fails to disclose where the unique peer identifier of one the peer 
nodes is formatted in accordance with a canonical representation scheme and where 
the unique peer identifier of a different one of the peer nodes is formatted in 
accordance with a different canonical representation scheme . The Examiner cites 
paragraphs 54 and 1100-1106 and refers to Weisman's device description scheme. 
Weisman teaches that the schema for UPnP device descriptions is known as the UPnP 
Template Language (UTL). Weisman's UTL is used to generate UPnP device 
descriptions. 

The Examiner equates Weisman's control URLs to the unique peer identifier's of 
Appellants' claims. While Weisman's UTL does specify that a device description may 
include several different URLs, it does not specify the formatting for any particular URL. 
Thus, Weisman's UTL does not represent a canonical representation scheme according to 
which a unique peer identifier formatted. Instead, at paragraph 131, Weisman describes a 
proprietary formatting of URLs. 

Furthermore, nowhere does Weisman mention anything about different canonical 
representation schemes used to format unique peer identifiers for different peer nodes. In 
fact, Weisman teaches away from using different schemes to format different peer 
identifiers. Weisman teaches a single formatting scheme for his control URLs, which the 
Examiner equates to the unique peer identifiers of Appellant's claims. By teaching the 
use of a single formatting scheme for all control URLs, Weisman clearly teaches away 
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from formatting different peer identifiers according to different canonical representation 
schemes. 

Claim 20 : 

Weisman fails to disclose where the member peers in one peer group are 
configured to use one canonical representation scheme to format unique peer 
identifiers within the peer group and where members of another peer group are 
configured to use a different canonical representation scheme to format unique peer 
identifiers within the different peer group . The Examiner cites paragraphs 349-355 
and 880-995, where Weisman discusses the NOTIFY message of his event submission 
architecture. The Examiner is apparently rejecting claim 20 in view of the fact that 
Weisman' s NOTIFY message may include multiple URIs for different devices. 
However, even a cursory reading of the cited passage demonstrates that Weisman uses a 
single formatting scheme for the URIs in this NOTIFY message. For example, at 
paragraphs 882, 884, 886, 896, 898, 900 and 902, Weisman includes respective example 
URIs (e.g., "upnp:rootdevice", "uuid:schemas-upnp-org:device:device-type:device- 
UUID", "urn:schemas-upnp-org:device:device-type", "urn:schema-upnp- 

org:service:service-type", "uuid:dcvicc-UUID::upnp:rootdevice", "uuid:device- 
UUID: :urn:schemas-upnp-org:device:deviceType:v", and "uuid:device- 

UUID::urn:schemas-upnp-org:service:serviceType:v"). However, all of the URIs 
discussed in the cited passages are formatted according to a single formatting scheme. 
Just because the different URIs may include different elements does not mean that they 
are formatted according to different formatting schemes. A single formatting scheme 
may easily encompass various elements, as does Weisman's. 

Moreover, the URIs of Weisman's NOTIFY message have nothing to do with 
member peers of different peer groups formatting peer identifiers according to different 
canonical representation schemes. In contrast, Weisman teaches, "[w]hen a device is 
added to the network, its sends a multicast request with method NOTIFY." Thus, 
Weisman teaches that his NOTIFY messages, including the URI's upon which the 



10/055,666 (5681-07700/P7116) 



26 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



Examiner relies in the rejection, when a device is added to the network. Weisman does 
not describe member nodes of different peer groups formatting peer identifiers using 
different versions of the URI's used in NOTIFY messages. 

Weisman clearly fails to disclose member peers in one peer group configured 
to use one canonical representation scheme to format unique peer identifiers within 
the peer group and member peers of another peer group configured to use a 
different canonical representation scheme to format unique peer identifiers within 
the different peer group . 

Third Ground of Rejection 

Claims 14, 16, 38, 40, 41, 60, 62, 64, 75, 77 and 79 stand finally rejected under 35 
U.S.C. § 103(a) as being unpatentable over Weisman in view of Ferguson et al. (U.S. 
Patent 6,490,6 1 8) (hereinafter "Ferguson"). Appellants traverse this rejection for at least 
the reasons presented above regarding their respective, independent claims. 
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CONCLUSION 



For the foregoing reasons, it is submitted that the Examiner's rejection of claims 
1-2, 4-20, 30-41 and 48-49 and 51-79 was erroneous, and reversal thereof is respectfully 
requested. 

The Commissioner is authorized to charge any fees that may be due to Meyertons, 
Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 501 505/568 1-07700/RCK. 



Respectfully submitted, 



/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
Attorney for Appellants 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

(512) 853-8850 

Date: January 14. 2008 
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VIII. CLAIMS APPENDIX 



The claims on appeal are as follows. 

1 . A peer computing system, comprising: 

a plurality of peer nodes operable to couple to a network; 

wherein the plurality of peer nodes are configured to implement a peer-to-peer 
environment on the network according to a peer-to-peer platform 
comprising: 

a core layer comprising one or more peer-to-peer platform protocols for 
enabling the plurality of peer nodes to discover each other, 
communicate with each other, and cooperate with each other to 
form peer groups and share content in the peer-to-peer 
environment; 

a service layer comprising one or more services each provided by one or 
more of the plurality of peer nodes in the peer-to-peer 
environment, wherein at least a subset of the services are operable 
to be used by the plurality of peer nodes in forming the peer groups 
and participating in the peer groups, and wherein each of the one 
or more services are configured to be accessed by the plurality of 
peer nodes in accordance with at least one of the one or more peer- 
to-peer platform protocols; and 

a unique peer identifier, wherein the peer identifier is configured for use in 
distinguishing a particular peer node from others of the plurality of 
peer nodes in the peer-to-peer environment, wherein the peer 
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identifier is independent of a network address of the particular peer 
node; 

wherein each of the plurality of peer nodes is further configured to access another 
of the plurality of peer nodes on the network using the unique peer 
identifier of the other peer node, wherein the peer node does not use a 
network address of the other peer node to access the other peer node. 

2. The peer computing system as recited in claim 1, wherein each of the 
plurality of peer nodes is further configured to bind a peer identifier corresponding to the 
particular peer node to the network address of the particular peer node. 

4. The peer computing system as recited in claim 1, wherein, to access the 
other peer node, the unique peer identifier of the other peer node is configured to be 
mapped to a network address of the other peer node. 

5. The peer computing system as recited in claim 1, wherein, to access the 
other peer node, the unique peer identifier of the other peer node is configured to be 
mapped to one of one or more network interfaces of the other peer node. 

6. The peer computing system as recited in claim 2, wherein each of the 
plurality of peer nodes is further configured to: 

unbind the peer identifier corresponding to the peer node from the network 
address; 

obtain a new network address; and 

bind the peer identifier corresponding to the peer node to the new network 
address. 
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7. The peer computing system as recited in claim 1, wherein each peer 
identifier is further configured for use in determining a particular peer group in which a 
particular peer node corresponding to the peer identifier is a member peer. 

8. The peer computing system as recited in claim 1, wherein each of the 
plurality of peer nodes is further configured to participate as a member peer in one or 
more peer groups in the peer-to-peer environment, and wherein each of the plurality of 
peer nodes is assigned a different unique peer identifier in accordance with the peer-to- 
peer platform for each of the one or more peer groups in which the peer node is a member 
peer. 

9. The peer computing system as recited in claim 1, wherein each of the 
plurality of peer nodes is further configured to: 

participate as a member peer in a plurality of peer groups in the peer-to-peer 
environment; 

receive a message from another of the plurality of peer nodes, wherein the other 
peer node is a member peer in a particular one of the plurality of peer 
groups in which the peer node is a member peer, and wherein the message 
includes a peer identifier of the other peer; and 

determine the particular one of the plurality of peer groups in which the other peer 
is a member peer from the peer identifier of the other peer. 

10. The peer computing system as recited in claim 9, wherein the message 
specifies a resource hosted by the peer node, wherein the peer node hosts a plurality of 
instances of the resource, wherein each of the instances of the resource is hosted for a 
different one of the plurality of peer groups, and wherein the peer node is further 
configured to access in accordance with the message a particular one of the instances of 
the resource hosted for the particular one of the plurality of peer groups in which the 
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other peer node is a member peer. 



11. The peer computing system as recited in claim 10, wherein the resource is 
a service, and wherein the instance of the resource is an instance of the service 
implemented on the peer node. 

12. The peer computing system as recited in claim 1, wherein the peer-to-peer 
platform defines a peer advertisement format for describing and publishing 
advertisements for peer nodes in the peer-to-peer environment, wherein each of the 
plurality of peer nodes is further configured to generate a peer advertisement for the 
particular peer node, wherein the peer advertisement includes a peer identifier for the 
peer node. 

13. The peer computing system as recited in claim 1, further comprising a 
plurality of resources accessible by the plurality of peer nodes in the peer-to-peer 
environment, wherein each resource corresponds to a unique resource identifier 
configured for use in distinguishing the particular resource from other resources of the 
plurality of resources in the peer-to-peer environment. 

14. The peer computing system as recited in claim 13, wherein the plurality of 
resources include one or more of peer groups, content, services, applications, pipes, and 
pipe endpoints, wherein pipes are communications channels between two or more peer 
nodes in the peer-to-peer environment, and wherein pipe endpoints are network interfaces 
on the peer nodes that are configured to be bound to the pipes to establish the 
communications channels. 

15. The peer computing system as recited in claim 1, wherein each of the one 
or more peer-to-peer platform protocols defines one or more advertisement formats for 
describing and publishing advertisements for resources in the peer-to-peer environment, 
wherein each of the plurality of peer nodes is further configured to: 
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host a plurality of resources accessible by the plurality of peer nodes in the peer- 
to-peer environment; and 



generate a resource advertisement for each resource corresponding to the 
particular peer node in accordance with the peer-to-peer platform, wherein 
at least a subset of the resource advertisements each include a peer 
identifier of the peer node. 

16. The peer computing system as recited in claim 15, wherein the resources 
include one or more of peer nodes, peer groups, content, services, applications, pipes, and 
pipe endpoints, wherein pipes are communications channels between two or more peer 
nodes in the peer-to-peer environment, and wherein the pipe endpoints are network 
interfaces on the peer nodes that are configured to be bound to the pipes to establish the 
communications channels. 

17. The peer computing system as recited in claim 15, wherein each resource 
is assigned a unique resource identifier configured for use in distinguishing the particular 
resource from other resources in the peer-to-peer environment, and wherein each resource 
advertisement further includes a resource identifier assigned to a particular resource 
corresponding to the resource advertisement. 

18. The peer computing system as recited in claim 1, wherein the one or more 
peer-to-peer platform protocols includes one or more of: 

a peer discovery protocol for discovering resources in the peer-to-peer 
environment, wherein the resources include one or more of peer nodes, 
peer groups, content, services, applications, pipes, and pipe endpoints, 
wherein pipes are communications channels between two or more peer 
nodes in the peer-to-peer environment, and wherein pipe endpoints are 
network interfaces on the peer nodes that are configured to be bound to the 
pipes to establish the communications channels; 
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a peer membership protocol for use by the peer nodes in applying for membership 
in the peer groups; 

a peer resolver protocol for use in sending search queries from one peer group 
member to another peer group member; 

a peer information protocol for enabling the peer nodes to obtain information 
about capabilities and status of other peer nodes in the peer-to-peer 
environment; 

a pipe binding protocol for use in finding the physical location of pipe endpoints 
and binding the pipe endpoints, wherein pipes are communications 
channels between two or more peer nodes in the peer-to-peer environment, 
and wherein pipe endpoints are network interfaces on the peer nodes that 
are configured to be bound to the pipes to establish the communications 
channels; and 

an endpoint routing protocol for enabling the peer nodes to request peer routing 
information to reach the other peer nodes. 

19. The peer computing system as recited in claim 1, wherein the unique peer 
identifier of one of the plurality of peer nodes is formatted in accordance with a canonical 
representation scheme, and wherein the unique peer identifier of a different one of the 
plurality of peer nodes is formatted in accordance with a different canonical 
representation scheme. 

20. The peer computing system as recited in claim 1, wherein the one of the 
plurality of peer nodes is a member peer in a peer group, wherein member peers in the 
peer group are configured to use the canonical representation scheme to format unique 
peer identifiers within the peer group, wherein the different one of the plurality of peer 



10/055,666 (5681-07700/P7116) 



54 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



nodes is a member peer in a different peer group, and wherein member peers in the 
different peer group are configured to use the different canonical representation scheme 
to format unique peer identifiers within the different peer group. 



30. A peer node, comprising: 

a network interface for coupling to a network; 

a memory comprising program instructions, wherein the program instructions are 
executable within the peer node to implement, according to a peer-to-peer 
platform: 

a core layer comprising one or more pccr-to-pccr platform protocols for 
enabling the peer node to discover other peer nodes, communicate 
with the other peer nodes, and cooperate with the other peer nodes 
to form peer groups and share content in a peer-to-peer 
environment on the network; 

a service layer comprising one or more services in the peer-to-peer 
environment, wherein at least a subset of the services are operable 
to be used by the peer node and the other peer nodes in forming the 
peer groups and participating in the peer groups, and wherein each 
of the one or more services are configured to be accessed in 
accordance with at least one of the one or more peer-to-peer 
platform protocols; and 

a unique peer identifier in accordance with the peer-to-peer platform, 
wherein the peer identifier is configured for use in distinguishing 
the peer node from other peer nodes in the peer-to-peer 
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environment, wherein the peer identifier is independent of a 
network address for the peer node; 

wherein the peer node is configured to access one of the other peer nodes 
using a unique peer identifier of the one of the other peer nodes, 
wherein the peer node does not use a network address of the one of 
the other peer nodes to access the one of the other peer nodes. 

31. The peer node as recited in claim 30, wherein the peer node is further 
configured to bind the peer identifier to the network address of the peer node. 

32. The peer node as recited in claim 31, wherein the peer node is further 
configured to: 

unbind the peer identifier from the network address; 

obtain a new network address; and 

bind the peer identifier to the new network address. 

33. The peer node as recited in claim 30, wherein the peer node is further 
configured to: 

participate as a member peer in a plurality of peer groups in the peer-to-peer 
environment; 

receive a message from another peer node, wherein the other peer node is a 
member peer in a particular one of the plurality of peer groups in which 
the peer node is a member peer, and wherein the message includes a peer 
identifier of the other peer; and 
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determine the particular one of the plurality of peer groups in which the other peer 
is a member peer from the peer identifier of the other peer. 

34. The peer node as recited in claim 30, wherein the peer node is further 
configured to: 

obtain a unique peer identifier of a different peer node on the network; and 

access the different peer node on the network using the unique peer identifier of 
the other peer node; 

wherein the peer node is not aware of a network address of the different peer 
node. 

35. The peer node as recited in claim 31, wherein the message specifies a 
service hosted by the peer node, wherein the peer node hosts a plurality of instances of 
the service, wherein each of the instances of the service is hosted for a different one of 
the plurality of peer groups, and wherein the peer node is further configured to provide 
the message to a particular one of the instances of the service hosted for the particular one 
of the plurality of peer groups in which the other peer node is a member peer. 

36. The peer node as recited in claim 30, wherein the peer-to-peer platform 
defines a peer advertisement format for describing and publishing advertisements for peer 
nodes in the peer-to-peer environment, wherein the peer node is further configured to 
generate a peer advertisement in accordance with the peer advertisement format, wherein 
the peer advertisement includes a peer identifier for the peer node. 

37. The peer node as recited in claim 30, further comprising a plurality of 
resources accessible by peer nodes in the peer-to-peer environment, wherein the peer 
node is further configured to assign each of the plurality of peer nodes a unique resource 
identifier configured for use in distinguishing the particular resource from other resources 
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in the peer-to-peer environment. 

38. The peer node as recited in claim 37, wherein the plurality of resources 
include one or more of content, services, applications, pipes, and pipe endpoints, wherein 
pipes are communications channels between two or more peer nodes in the peer-to-peer 
environment, and wherein pipe endpoints are network interfaces on the peer node 
configured to be bound to the pipes to establish the communications channels. 

39. The peer node as recited in claim 30, wherein each of the one or more 
peer-to-peer platform protocols defines one or more advertisement formats for describing 
and publishing advertisements for resources in the peer-to-peer environment, wherein the 
peer node is further configured to generate a resource advertisement for at least a subset 
of a plurality of resources on the peer node, wherein the resource advertisements each 
include the peer identifier for the peer node. 

40. The peer node as recited in claim 39, wherein the plurality of resources 
include one or more of content, services, applications, pipes, and pipe endpoints, wherein 
pipes are communications channels between two or more peer nodes in the peer-to-peer 
environment, and wherein pipe endpoints are network interfaces on the peer node 
configured to be bound to the pipes to establish the communications channels. 

41 . The peer node as recited in claim 30, wherein the one or more peer-to-peer 
platform protocols includes a peer discovery protocol for discovering resources in the 
peer-to-peer environment, wherein the resources include one or more of peer nodes, peer 
groups, content, services, applications, pipes, and pipe endpoints, wherein pipes are 
communications channels between two or more peer nodes in the peer-to-peer 
environment, and wherein pipe endpoints are network interfaces on peer nodes that are 
configured to be bound to the pipes to establish the communications channels. 

48. A method for implementing a peer-to-peer environment on a network, the 
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method comprising: 

a plurality of peer nodes coupled to a network each implementing a core layer of a 
peer-to-peer platform, wherein the core layer comprises one or more peer- 
to-peer platform protocols for enabling the plurality of peer nodes to 
discover each other, communicate with each other, and cooperate with 
each other to form peer groups and share content in the peer-to-peer 
environment; 

the plurality of peer nodes each implementing a service layer comprising one or 
more services each provided by one or more of the plurality of peer nodes 
in the peer-to-peer environment, wherein each of the one or more services 
are configured to be accessed by peer nodes in the peer-to-peer 
environment in accordance with at least a subset of the one or more peer- 
to-peer platform protocols; and 

assigning a unique peer identifier to each of the plurality of peer nodes, wherein 
each unique peer identifier is configured for use in distinguishing a 
particular peer node from others of the plurality of peer nodes in the peer- 
to-peer environment, wherein the peer identifier is independent of a 
network address of the particular peer node; 

one of the plurality of peer nodes accessing another of the plurality of peer nodes 
on the network using the unique peer identifier of the other peer node, 
wherein the peer node does not use a network address of the other peer 
node to access the other peer node. 

49. The method as recited in claim 48, further comprising binding the peer 
identifier of each of the plurality of peer nodes to the network address of the respective 
peer node. 
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51. The method as recited in claim 49, wherein, in said accessing the other 
peer node, the method further comprises mapping the unique peer identifier of the other 
peer node to a network address of the other peer node. 

52. The method as recited in claim 49, wherein, in said accessing the other 
peer node, the method further comprises mapping the unique peer identifier of the other 
peer node to one of one or more network interfaces of the other peer node. 

53. The method as recited in claim 49, further comprising: 

one of the plurality of peer nodes unbinding the peer identifier corresponding to 
the peer node from the network address of the peer node; 

the peer node obtaining a new network address; and 

the peer node binding the peer identifier corresponding to the peer node to the 
new network address. 

54. The method as recited in claim 48, further comprising: 

at least a subset of the plurality of peer nodes accessing at least a subset of the 
core services in accordance with at least one of the one or more peer-to- 
peer platform protocols to form one or more peer groups in the peer-to- 
peer environment; 

wherein each peer identifier is further configured for use in determining a 
particular one of the one or more peer groups in which a particular peer 
node corresponding to the peer identifier is a member peer. 

55. The method as recited in claim 48, further comprising: 
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at least a subset of the plurality of peer nodes accessing at least a subset of the 
core services in accordance with at least one of the one or more peer-to- 
peer platform protocols to form one or more peer groups in the peer-to- 
peer environment; and 

wherein each of the plurality of peer nodes is assigned a different unique peer 
identifier in accordance with the peer-to-peer platform for each of the one 
or more peer groups in which the peer node is a member peer. 

56. The method as recited in claim 48, further comprising: 

at least a subset of the plurality of peer nodes accessing at least a subset of the 
core services in accordance with at least one of the one or more peer-to- 
peer platform protocols to form one or more peer groups in the peer-to- 
peer environment; 

one of the at least a subset of the plurality of peer nodes receiving a message from 
another of the at least a subset of the plurality of peer nodes, wherein the 
other peer node is a member peer in a particular one of the one or more 
peer groups in which the peer node is a member peer, and wherein the 
message includes a peer identifier of the other peer; and 

determining the particular one of the plurality of peer groups in which the other 
peer is a member peer from the peer identifier of the other peer. 

57. The method as recited in claim 56, wherein the message specifies a service 
hosted by the peer node, wherein the peer node hosts a plurality of instances of the 
service, wherein each of the instances of the service is hosted for a different one of the 
one or more peer groups of which the peer node is a member peer, and wherein the 
method further comprises the peer node providing the message to a particular one of the 
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instances of the service hosted for the determined particular one of the one or more peer 
groups in which the other peer node is a member peer. 

58. The method as recited in claim 48, wherein the peer-to-peer platform 
defines a peer advertisement format for describing and publishing advertisements for peer 
nodes in the peer-to-peer environment, wherein the method further comprises generating 
a peer advertisement for one of the plurality of peer nodes, wherein the peer 
advertisement includes a peer identifier for the peer node. 

59. The method as recited in claim 48, further comprising at least a subset of 
the plurality of peer nodes hosting a plurality of resources accessible by the plurality of 
peer nodes in the peer-to-peer environment, wherein each resource is assigned a unique 
resource identifier configured for use in distinguishing the particular resource from other 
resources in the peer-to-peer environment. 

60. The method as recited in claim 59, wherein the plurality of resources 
include one or more of peer groups, content, services, applications, pipes, and pipe 
endpoints, wherein pipes are communications channels between two or more peer nodes 
in the peer-to-peer environment, and wherein pipe endpoints are network interfaces on 
the peer nodes that are configured to be bound to the pipes to establish the 
communications channels. 

61. The method as recited in claim 48, wherein the one or more peer-to-peer 
platform protocols define one or more advertisement formats for describing and 
publishing advertisements for resources in the peer-to-peer environment, the method 
further comprising: 

at least a subset of the plurality of peer nodes hosting a plurality of resources 
accessible by the plurality of peer nodes in the peer-to-peer environment; 
and 
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generating a resource advertisement for each of the plurality of resources in 
accordance with the one or more peer-to-peer platform protocols, wherein 
at least a subset of the resource advertisements each include one or more 
peer identifiers each corresponding to one of the plurality of peer nodes 
associated with the particular resource corresponding to the particular 
resource advertisement. 

62. The method as recited in claim 61, wherein the resources include one or 
more of peer nodes, peer groups, content, services, applications, pipes, and pipe 
endpoints, wherein pipes are communications channels between two or more peer nodes 
in the peer-to-peer environment, and wherein the pipe endpoints are network interfaces 
on the peer nodes that are configured to be bound to the pipes to establish the 
communications channels. 

63. The method as recited in claim 61, wherein each resource is assigned a 
unique resource identifier configured for use in distinguishing the particular resource 
from other resources in the peer-to-peer environment, and wherein each resource 
advertisement further includes a resource identifier assigned to a particular resource 
corresponding to the resource advertisement. 

64. The method as recited in claim 48, wherein the one or more peer-to-peer 
platform protocols include one or more of: 

a peer discovery protocol for discovering resources in the peer-to-peer 
environment, wherein the resources include one or more of peer nodes, 
peer groups, content, services, applications, pipes, and pipe endpoints, 
wherein pipes are communications channels between two or more peer 
nodes in the peer-to-peer environment, and wherein pipe endpoints are 
network interfaces on the peer nodes that are configured to be bound to the 
pipes to establish the communications channels; and 



10/055,666 (5681-07700/P7116) 



45 



Meyertons, Hood, Kivlin, Kowert & Goetzel, P.C. 



a peer membership protocol for use by the peer nodes in applying for membership 
in the peer groups. 

65. The method as recited in claim 48, wherein, in said assigning a unique 
peer identifier to each of the plurality of peer nodes, the method further comprises: 

formatting the unique peer identifiers of a subset of the plurality of peer nodes 
according to a canonical representation scheme; and 

formatting the unique peer identifiers of a different subset of the plurality of peer 
nodes according to a different canonical representation scheme. 

66. An article of manufacture comprising software instructions executable to 
implement: 

a plurality of peer nodes coupled to a network each implementing a core layer of a 
peer-to-peer platform, wherein the core layer comprises one or more peer- 
to-peer platform protocols for enabling the plurality of peer nodes to 
discover each other, communicate with each other, and cooperate with 
each other to form peer groups and share content in a peer-to-peer 
environment; 

the plurality of peer nodes each implementing a service layer comprising one or 
more services each provided by one or more of the plurality of peer nodes 
in the peer-to-peer environment, wherein each of the one or more services 
are configured to be accessed by peer nodes in the peer-to-peer 
environment in accordance with at least a subset of the one or more peer- 
to-peer platform protocols; and 
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assigning a unique peer identifier to each of the plurality of peer nodes, wherein 
each peer identifier is configured for use in distinguishing the respective 
peer node from others of the plurality of peer nodes in the peer-to-peer 
environment, wherein the peer identifier of a respective peer node is 
independent of a network address of the respective peer node; 

wherein each of the plurality of peer nodes is configured to access another of the 
plurality of peer nodes using the unique peer identifier of the other peer 
node, wherein the peer node does not use a network address of the other 
peer node to access the other peer node. 

67. The article of manufacture as recited in claim 66, wherein the software 
instructions are further executable to implement binding the peer identifier corresponding 
to a respective one of the plurality of peer nodes to the network address of the respective 
peer node. 

68. The article of manufacture as recited in claim 67, wherein the software 
instructions are further executable to implement: 

unbinding the peer identifier corresponding to the peer node from the network 
address; 

obtaining a new network address for the peer node; and 

binding the peer identifier corresponding to the peer node to the new network 
address. 

69. The article of manufacture as recited in claim 66, wherein the software 
instructions are further executable to implement: 
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at least a subset of the plurality of peer nodes accessing at least a subset of the 
core services in accordance with at least one of the one or more peer-to- 
peer platform protocols to form one or more peer groups in the peer-to- 
peer environment; 

wherein each peer identifier is further configured for use in determining a 
particular one of the one or more peer groups in which a particular peer 
node corresponding to the peer identifier is a member peer. 

70. The article of manufacture as recited in claim 66, wherein the software 
instructions are further executable to implement: 

at least a subset of the plurality of peer nodes accessing at least a subset of the 
core services in accordance with at least one of the one or more peer-to- 
peer platform protocols to form one or more peer groups in the peer-to- 
peer environment; and 

wherein each of the plurality of peer nodes is assigned a different unique peer 
identifier in accordance with the peer-to-peer platform for each of the one 
or more peer groups in which the peer node is a member peer. 

71. The article of manufacture as recited in claim 66, wherein the software 
instructions are further executable to implement: 

at least a subset of the plurality of peer nodes accessing at least a subset of the 
core services in accordance with at least one of the one or more peer-to- 
peer platform protocols to form one or more peer groups in the peer-to- 
peer environment; and; 

one of the at least a subset of the plurality of peer nodes receiving a message from 
another of the at least a subset of the plurality of peer nodes, wherein the 
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other peer node is a member peer in a particular one of the one or more 
peer groups in which the peer node is a member peer, and wherein the 
message includes a peer identifier of the other peer; and 

determining the particular one of the plurality of peer groups in which the other 
peer is a member peer from the peer identifier of the other peer. 

72. The article of manufacture as recited in claim 71, wherein the message 
specifies a service hosted by the peer node, wherein the peer node hosts a plurality of 
instances of the service, wherein each of the instances of the service is hosted for a 
different one of the one or more peer groups of which the peer node is a member peer, 
and wherein the software instructions are further executable to implement the peer node 
providing the message to a particular one of the instances of the service hosted for the 
determined particular one of the one or more peer groups in which the other peer node is 
a member peer. 

73. The article of manufacture as recited in claim 66, wherein the peer-to-peer 
platform defines a peer advertisement format for describing and publishing 
advertisements for peer nodes in the peer-to-peer environment, wherein the software 
instructions are further executable to implement generating a peer advertisement for one 
of the plurality of peer nodes, wherein the peer advertisement includes a peer identifier 
for the peer node. 

74. The article of manufacture as recited in claim 66, further comprising at 
least a subset of the plurality of peer nodes hosting a plurality of resources accessible by 
the plurality of peer nodes in the peer-to-peer environment, wherein each resource is 
assigned a unique resource identifier configured for use in distinguishing the particular 
resource from other resources in the peer-to-peer environment. 

75. The article of manufacture as recited in claim 74, wherein the plurality of 
resources include one or more of peer groups, content, services, applications, pipes, and 
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pipe endpoints, wherein pipes are communications channels between two or more peer 
nodes in the peer-to-peer environment, and wherein pipe endpoints are network interfaces 
on the peer nodes that are configured to be bound to the pipes to establish the 
communications channels. 

76. The article of manufacture as recited in claim 66, wherein the one or more 
peer-to-peer platform protocols define one or more advertisement formats for describing 
and publishing advertisements for resources in the peer-to-peer environment, wherein the 
software instructions are further executable to implement: 

at least a subset of the plurality of peer nodes hosting a plurality of resources 
accessible by the plurality of peer nodes in the peer-to-peer environment; 
and 

generating a resource advertisement for each of the plurality of resources in 
accordance with the one or more peer-to-peer platform protocols, wherein 
at least a subset of the resource advertisements each include one or more 
peer identifiers each corresponding to one of the plurality of peer nodes 
associated with the particular resource corresponding to the particular 
resource advertisement. 

77. The article of manufacture as recited in claim 76, wherein the resources 
include one or more of peer nodes, peer groups, content, services, applications, pipes, and 
pipe endpoints, wherein pipes are communications channels between two or more peer 
nodes in the peer-to-peer environment, and wherein the pipe endpoints are network 
interfaces on the peer nodes that are configured to be bound to the pipes to establish the 
communications channels. 

78. The article of manufacture as recited in claim 76, wherein each resource is 
assigned a unique resource identifier configured for use in distinguishing the particular 
resource from other resources in the peer-to-peer environment, and wherein each resource 
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advertisement further includes a resource identifier assigned to a particular resource 
corresponding to the resource advertisement. 

79. The article of manufacture as recited in claim 66, wherein the one or more 
peer-to-peer platform protocols include one or more of: 

a peer discovery protocol for discovering resources in the peer-to-peer 
environment, wherein the resources include one or more of peer nodes, 
peer groups, content, services, applications, pipes, and pipe endpoints, 
wherein pipes are communications channels between two or more peer 
nodes in the peer-to-peer environment, and wherein pipe endpoints are 
network interfaces on the peer nodes that are configured to be bound to the 
pipes to establish the communications channels; and 

a peer membership protocol for use by the peer nodes in applying for membership 
in the peer groups. 
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IX. EVIDENCE APPENDIX 

No evidence submitted under 37 CFR §§ 1.130, 1.131 or 1.132 or otherwise 
entered by the Examiner is relied upon in this appeal. 
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X. RELATED PROCEEDINGS APPENDIX 

There are no related proceedings. 
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